Traditionally, policers are each implemented as one entry inside a physical memory. As a result, access during each cycle is limited to a single call and write of the memory bank and thus a single policer per cycle. This causes problems when traffic from multiple pipelines wants to access the same policer during the same cycle. As a result, it limits the ability to adjust for situations where the traffic rate is exceeding memory bandwidth. Thus, the policer architecture has the drawback of limited capabilities without increasing physical memory access which conversely increases memory costs.
In communications, traffic policing is the process of monitoring network traffic with policers for compliance with a traffic contract and taking steps to enforce that contract. Traffic sources which are aware of a traffic contract may apply traffic shaping to ensure their output stays within the contract and is thus not discarded. Traffic exceeding a traffic contract may be discarded immediately, marked as non-compliant, or left as-is, depending on administrative policy and the characteristics of the excess traffic. Policers that are implemented as one entry inside physical memory limit the system to only one access to one policer per cycle such that no multiple requests possible. This creates the drawback of preventing traffic from a plurality of pipelines trying to access the same policer, preventing traffic from multiple processing elements trying to access the same policer and/or limiting the system to be only able to handle traffic rates withing the memory bandwidth.